1. Field of the Invention
The present invention relates to the field of SOA architecture deployment technologies and, more particularly, to a repeatable and standardized approach for deploying a portable SOA infrastructure within a client environment, which leverages existing integration assets and that transfers skills relating to the deployed SOA solution to a client's IT team.
2. Description of the Related Art
A Service Oriented Architecture (SOA) is an information technology infrastructure which abstracts business services and separates them from applications to yield an overall system that is easier to build, maintain, and extend than traditional systems. That is, services in a SOA serve as an abstraction layer that hides core system implementation from clients and provides a simple loosely coupled way to integrate both service consumer and provider. The coupling is based upon simple XML based messages and open standards that describe the protocol for service discovery and invocation (e.g., WSDL, SOAP, UDDI). In a SOA infrastructure, the infrastructure components that determine the communication system do not affect the interfaces. Each interaction is independent of each and every other interaction and the interconnect protocols of the communicating devices.
Critics of an SOA approach have argued, with some validity, that SOA often focuses on application design and construction and is only secondarily concerned with distribution. That is, SOA platforms permit developers to turn any set of programming language objects directly into a set of distributed services regardless of the objects suitability for distribution. In other words, many existing SOA platform and implementation approaches focus too heavily upon a programming-language level during early development stages and not heavily enough at the distribution level, ignoring long standing lessons that adding distribution elements after the fact to developed software simply does not yield positive results.
To illustrate the problem, consider that each SOA component can define its own input/output parameters, configuration options, performance characteristics, and the like. Many existing SOA components are effectively “SOAP wrapped” legacy components, which have been repurposed for a SOA architecture. Although there is nothing inherently wrong with this practice, which can be highly advantageous in many situations, connecting or interfacing various SOA components can be extremely challenging, time consuming, and costly. Further, SOA components generally must be deployed to a client software/hardware infrastructure at some point, which can depend upon design characteristics of individual SOA components.
In other words, the flexibility of a SOA architecture can be a disadvantage in that solutions can be patched together easily that contain many ill fitting components, which results in maintenance and upgrading problems, poor performance, and other issues. Many negative connotations have been attributed to SOA architectures that are less inherent problems of an SOA approach and more problems relating to poor SOA deployment choices and lack of knowledge concerning a valid deployment environment. For example, a client receiving a SOA solution may not fully understand the solution being purchased, its limitations, and its expected maintenance and upgrade costs. A SOA deployment team similarly may not understand a client's environment and solution goals, which can result in less than ideal choices for the client being made, as the SOA solution is selected/constructed/deployed.
One solution to minimize many potential problems with integrating SOA components is to establish a reference SOA solution consisting of numerous “plug-and-play” software SOA components. For example, U.S. patent application Ser. No. 11/232,159 filed Sep. 21, 2005 and entitled “Service-Oriented Architecture for Enterprises That Supports Multiple Interface Channels”, discloses a SOA infrastructure framework shown in FIG. 1 (Prior Art). Other SOA architectures can be used as a reference SOA solution, and the one shown in FIG. 1 is not intended to limit the scope of a reference model. The FIG. 1 provides different clients 110 with presentation services 120 and application services 122 through a service gateway 126. A set of resources 130 can be connected to the service gateway 126 via a service bus 132. An integration service provider 134 can integrate the back-end resources 130 and can provide a consistent interface with the service gateway 126.
While reference SOA solutions can help alleviate many potential problems, many deployment specific issues still arise. FIG. 2 (Prior Art) depicts a software component model 200 (target model), which is a deployed instance of the SOA framework (reference model) shown in FIG. 1. A typical approach to deploying the target model 200 can involve:                (1) Taking into account software components (products) already purchased, corporate standards, industry standards, and/or end user preferences and identifying one or more candidate components for performance of each function within the SOA framework (of FIG. 1).        (2) Installing/configuring the software components.        (3) Implementing techniques to orchestrate the SOA framework, such that the software components effectively work together.        (4) Testing the resulting implementation.        
At present, it is common to begin implementation of the software component model by going through the above steps as if constructing the model was a unique endeavor. That is, every implementation instance is approached as unique. Deployments are dependent upon experience levels and preferences of an asset deployment team and are generally performed in manner lacking uniformity among different deployments and teams, and lessons learned and best practices are not institutionalized into a systematic, repeatable process. Clients are often minimally involved in the SOA solution deployment process, which results in poor client understanding of a resulting SOA solution. A client's IT team, as a result of imperfect understanding of the implemented SOA solution, has difficulty maintaining the SOA solution and enhancing the system for future application functional requirements.
What is needed is a systematic approach to deploy a “portable” SOA infrastructure (reference model) into a client environment (creating a target model), which leverages integration assets from past deployments. Ideally, the deployment of this SOA based solution can include a knowledge transfer of implementation specifics to a client's development team. An optimal deployment approach would be standardized and repeatable, which would minimize risks taken by a deployment team (integration assets owner) in meeting their client's needs and contracted deadlines, which would in turn minimize client risks in adopting a SOA solution.